昨天你做了一個艱難的決定：把 Brent 從 Phoenix 關鍵路徑移除。今天，你要面對另一個關於 Brent 的真相——那些「英雄救援」背後，是什麼在默默殺死你的團隊。

早上九點二十三分：災難已經發生

Phoenix 部署失敗，整個 Production 生產環境陷入癱瘓。

你盯著監控面板上一片血紅的警告燈，腦子裡只有一個念頭：「快找 Brent。」

你撥打他的手機。沒人接聽。再次撥打，依然無人回應。你轉頭看了一眼行事曆，心涼了半截——Brent 今天休假，飛往西岸參加他妹妹的婚禮。此時他正在飛機上，手機處於關機狀態。

會議室裡，十幾個人面面相覷地盯著你。Ops 團隊、Dev 團隊、網路團隊全部到齊了。每個人都隱約知道問題出在哪個環節——Phoenix 的部署腳本需要手動調整三個環境變數，接著用特定的順序重啟五個服務。然而，這些精細的步驟只有 Brent 一個人真正懂。

有人試著翻找「文件」照步操作，但那份文件是八個月前的，早就過期失效了。有人試圖進行回滾（Rollback），但連回滾腳本都壞了——因為上次 Brent 緊急救火時「順手」改了某些參數，改完後並沒有記錄下來。

你看了一眼商業儀表板：公司此時每分鐘損失高達 $12,000$ 美元。客服部門的電話早已經被打爆。

你們就只能在會議室裡乾等著，等 Brent 的飛機落地。

三小時後：英雄歸來

下午一點，Brent 的手機終於開機。他看到 47 則未讀的緊急訊息，隨即直接打給你。

「現在是什麼狀況？」

你以最快的速度向他描述了故障現場。Brent 沒有半句廢話，立刻遠端連線進來，手指在鍵盤上飛快敲擊。短短五分鐘後，系統便全部恢復正常。

會議室裡響起如釋重負的嘆息聲。有人慶幸地說：「還好有 Brent 在。」

Steve 隔天在全員大會上高調表揚了 Brent：「即使是在休假，Brent 還是即時回應，在五分鐘內挽救了整個公司。這才是我們需要的優秀工程師！」台下掌聲雷動。

那天晚上，管理層召開了「事故檢討會議」，最終得出了一個結論：

「以後別讓 Brent 一次休假太久。或者至少，他休假時手機必須保持開機。」

這個結論，正是逐步殺死這個團隊的致命毒藥。

回推：單點瓶頸是怎麼養成的？

這絕不是第一次「等待 Brent 救援」。在過去的六個月裡，類似的場景已經發生過不下十次：

• 某個 API Gateway 設定有瑕疵，只有 Brent 知道那個「神奇的參數」是什麼。
• 某次資料庫容災切換（Failover），只有 Brent 記得「要手動刪掉那個 Lock 檔案」。
• 某次部署掛掉，只有 Brent 知道「必須先重啟服務 C，再重啟 B，最後重啟 A」。

每一次，Brent 都像救世主一樣及時出現，三兩下搞定，大家鬆一口氣，然後一切照舊，什麼都沒有改變。

為什麼？因為每一次「Brent 拯救世界」的成功，都讓組織學到了錯誤的教訓：

1. Brent 真的很厲害（這是事實）。
2. 所以我們未來需要更加依賴 Brent（這是致命錯誤）。

沒有人追問：「為什麼這些知識只有 Brent 一個人知道？」「為什麼系統沒有文件？」「為什麼沒有實現自動化？」

每一次成功的英雄式救援，都在加深組織對他的依賴。每一次的掌聲，都在**獎勵單點瓶頸（Single Point of Failure）**的持續存在。

這就是《鳳凰專案》中呈現最殘酷的現實：盲目的英雄主義從不是解法，它只是系統生病的表徵。

真正的問題：計畫外工作正在殺死你

我們來看看 Brent 過去一個月真實的時間分配：

📊 Brent 歷史月度時間分配（總時數：152 小時）

• ⚙️ 計畫內工作（如 Phoenix 功能開發）：占 $23%$ ── [█████████]
• 🚨 計畫外工作（如線上緊急救火）：占 $47%$ ── [███████████████████]
• 👥 行政會議與跨團隊協作：占 $18%$ ── [███████]
• 🧠 核心思考與系統設計：占 $12%$ ── [█████]

📈 中斷數據分析：單月累計救火 $47$ 次，平均每次中斷耗時 $1.5$ 小時，被中斷前最長連續工作時間僅為 $2.3$ 小時。

$47%$——接近一半的工作時間，通通花在臨時救火上。這些救火在精實思維中被歸類為「計畫外工作」（Unplanned Work）。

計畫外工作有一個特性：它永遠看起來比計畫內工作更緊急。當 Production 生產環境著火時，沒有人會理智地說「讓 Brent 寫完他手上那段重要程式碼再來」。你會直接粗暴地把 Brent 從他正在專注的工作中強行拉走。

結果就是：Phoenix 專案進度無限期延誤。因為 Brent 永遠在救火。而他越救火，系統就越脆弱、越依賴他，下一次的火災就越快在預期外引爆。

這是一個經典的死亡螺旋：

graph TD
    A[Brent 是唯一懂的人] --> B[系統出問題只能找他]
    B --> C[Brent 去救火]
    C --> D[計畫內工作延遲]
    D --> E[技術債累積]
    E --> F[系統更脆弱]
    F --> B
    C --> G[沒時間寫文件/自動化]
    G --> A

你看清楚了嗎？每一次手動救火，都在為下一次的系統爆炸埋下新的引信。

你的兩難

現在，你面對一個關鍵的抉擇：

Steve 的想法是選項 A。他說：「Brent 是我們最寶貴的資產，我們必須確保他隨時能出動救火。」

但你非常清楚，這樣下去 Brent 遲早會過勞離職，或者下一次真的遭遇「完全失聯」的危險——那時候，整家公司就完了。

先別往下看。如果是你，會選哪一條路？

翻牌：計畫外工作才是真正的敵人

正確答案是 選項 B。但這不是因為「Brent 不重要」，而是因為計畫外工作（Unplanned Work）是扼殺團隊交付能力最具破壞性的隱形殺手。

《鳳凰專案》裡，Erik Reid 教導 Bill 的第一課：工作有四種類型：

1. 🎯 業務專案（Business Projects）：例如 Phoenix 專案。
2. 🔧 內部 IT 專案（Internal Projects）：例如升級基礎設施、重構系統。
3. 📝 變更（Changes）：例如日常部署、Config 參數微調。
4. 🚨 計畫外工作（Unplanned Work）：如線上修復、緊急救火、反覆重工。

第四種才是真正的殺手。因為它會：

• 毫無預警地吃掉其他三種工作的既有產能（Capacity）。
• 不斷打斷瓶頸資源（如 Brent）的深度專注時間。
• 讓所有的開發時程與承諾變得無法預估。

更糟糕的是，計畫外工作通常都是前三類工作「做得不好」所產生的代價：欠下的技術債沒還、變更沒有經過嚴格審查、測試不足，以及系統文件缺失。

因此，真正的解法從不是「提升救火的速度」，而是「徹底消滅需要救火的根源」。

你採取了三項強制性措施：

1. 強制知識轉移

你把 Brent 找過來，嚴肅地說：「從今天起，你的核心 KPI 將是『教會其他兩個人處理你現在負責的事』。不是要你寫長篇大論的文件，而是實際帶著他們結對做一次。」

Brent 起初有些不情願，但你態度堅決。你甚至將此列為 Phoenix 專案的關鍵阻礙點——在知識成功移轉之前，Phoenix 專案拒絕進行任何新的部署。

2. 建立輕量化 Runbook

你規定每次 Brent 完成救火後，必須強迫自己花 30 分鐘撰寫一份極簡的「下次遇到該怎麼辦」步驟清單：

📑 Phoenix 部署失敗自動化 Runbook 範本：

1. 變數稽查：檢查環境變數 DEPLOY_MODE, API_TIMEOUT, DB_POOL_SIZE。
2. 重啟拓撲：依照順序重啟服務：service_c $\rightarrow$ service_b $\rightarrow$ service_a。
3. 服務驗證：發送請求驗證：curl http://health_check 應回傳 200 OK。
4. 異常處理：若仍失敗，檢查 /var/log/deploy.log 第 47 行的輸出紀錄。

如此一來，下次再出事，至少有八成的機會可以由其他工程師照表解決。

3. 常見故障自動化

你調出過去三個月的 Incident 統計，驚訝地發現有 $30%$ 是重複的「重啟服務」、$25%$ 是「手動微調參數」、$15%$ 是「清空過載暫存」。這三者加起來就佔了整整 $70%$ 的工作量，且都是機械式操作，根本不需要動用 Brent 的大腦。

你指派了另一位工程師，花一週時間將這些重複場景改寫為自動化修復腳本。下次再度遭遇時，點擊一個按鈕即可自動排除，無須等待 Brent。

如果有 AI Agent：從「等 Brent」變成「Agent 先試」

在 2026 年，這個救火場景可以完全改寫。

想像一下：當 Phoenix 部署再度失敗時，在你們手忙腳亂撥打 Brent 電話之前，AI 值班助手早已經自動啟動了：

graph LR
    A[部署失敗警報] --> B[AI 值班助手]
    B --> C{診斷步驟}
    C --> D[檢查歷史 runbook]
    C --> E[掃描 log 關鍵字]
    C --> F[比對過去 47 次類似 incident]
    D --> G{找到匹配}
    G -->|>=80% 信心| H[自動執行修復腳本]
    G -->|50% 信心| I[提供候選方案給人類]
    G -->|<30% 信心| J[呼叫 Brent]
    H --> K[5 分鐘內恢復]
    I --> K
    J --> L[Brent 介入,Agent 記錄新知識]

AI 不是要掠奪 Brent 的工作，而是要把他從無意義的「救火例行公事」中解放出來，讓他只專注處理全新的未知難題。

這正是 2026 年成熟的運作模式：

• Runbook 自動化：AI 能將歷史的步驟快速轉化為可執行的自動化腳本。
• 模式識別：在第一時間從 Log 中解析出「本次異常與上週的某次事故相似度達 $90%$」。
• 知識積累：每次 Brent 介入修復，AI 都在一旁默默學習、記錄，下一次相同問題它便能自行排除。

這能帶來顯著的成效：

• 平均修復時間（MTTR）從「等 Brent 落地開機的 3 小時」，縮短為「Agent 先行修復的 5 分鐘」。
• Brent 的計畫外工作比例從 $47%$ 驟降至 $15%$。
• 團隊的巴士因子（Bus Factor）不再是危險的 1，至少 AI 與其他成員能合力擋下第一波衝擊。

現場推演：那次半夜 Pipeline 掛掉

我們來看一個業界常見的真實案例（綜合改編，非特定專案）：

🏢 ETL Pipeline 憑證失效案例：

• 事件背景：核心 ETL 資料管線於半夜兩點崩潰，錯誤訊息顯示為 PermissionDenied: cannot write to s3://bucket/path。
• 瓶頸主因：該管線的 S3 存取權限由資深資料工程師 Alex 於三年前手動配置且未記錄。當時他正在休假且手機靜音，團隊在沒有 Runbook 的情況下盲目嘗試，反倒搞壞了其他 Production 儲存桶。
• 正確做法：
  1. 故障排除後，強制要求 Alex 花 30 分鐘撰寫「憑證過期緊急處置 Runbook」。
  2. 將金鑰管理納入自動化轮转機制（Rotation）。
  3. 導入 AI 監控提前預警憑證到期日，而非等崩潰才救火。

但如果組織的文化仍然是在隔天開會時「慶祝 Alex 昨晚又爆肝救了大家」，這些自動化與防範機制就永遠沒有落地的一天。

今日金句

「每一次英雄救援的掌聲，都是在幫下一場更大的災難鋪路。」

留給你的問題

在你們團隊上一次的「關鍵英雄救援」之後，有人將那次除錯的知識轉化為文件與 Runbook 嗎？還是大家只是鬆了一口氣，然後就忘得一乾二淨？

如果你的答案是後者，那麼你們的團隊正在走向同一個危險的陷阱：試圖用虛無的英雄主義，去掩蓋落後且千瘡百孔的系統性問題。

明天，我們要面對一個更艱難的對話：當 CEO 一味只要「快」，你怎麼有底氣告訴他「現在強行上線，後果會更慘」？

Day 6 見。